libs/application/templates/aosh/work-accident-notification/src/shared/constants.ts (1)

10-10: Add type annotation and documentation for MAX_EMPLOYEES constant

The constant would benefit from explicit typing and documentation explaining its purpose and any business rules behind the value of 20.

Consider applying this improvement:

-export const MAX_EMPLOYEES = 20
+/** Maximum number of employees that can be added to a work accident notification.
+ * This limit is enforced in the AddEmployee component and WorkAccidentNotificationForm.
+ */
+export const MAX_EMPLOYEES: number = 20

libs/application/templates/aosh/work-accident-notification/src/index.ts (1)

6-6: Add JSDoc documentation for the exported type

To improve reusability and maintainability across different NextJS apps, consider adding JSDoc documentation for the exported type.

+/**
+ * Represents the complete structure of a work accident notification form.
+ * This type is used across different components to ensure consistent data handling.
+ */
export type WorkAccidentNotification = WorkAccidentNotificationAnswers

libs/application/templates/aosh/work-accident-notification/src/fields/TypeOfInjury/index.tsx (1)

Line range hint 1-35: Component structure looks good but consider enhancing reusability

The component follows TypeScript best practices with proper type definitions. However, since this is in the libs/ directory, consider making the following aspects more reusable:

• The CausesAndEffects component could potentially be generalized for other form scenarios
• The message imports could be made configurable through props

libs/application/templates/aosh/work-accident-notification/src/fields/CauseOfInjury/index.tsx (1)

Line range hint 25-46: LGTM: Reusable component implementation

The component follows best practices for reusability:

• Uses generic FieldBaseProps for consistency across forms
• Implements proper type safety with optional chaining
• Maintains clear separation of concerns with CausesAndEffects subcomponent

Consider extracting the answer type casting to a custom hook for reuse across similar components:

function useWorkAccidentAnswers(application: Application) {
  return application.answers as WorkAccidentNotification
}

libs/application/templates/aosh/work-accident-notification/src/fields/EmployeeStartTimeError/index.tsx (1)

Line range hint 1-65: Well-structured component with good TypeScript practices!

The component demonstrates several good practices:

• Strong TypeScript typing with proper interfaces
• Effective use of React hooks (useState, useFormContext)
• Clear error handling and validation logic
• Modular and reusable design

Consider extracting the date validation logic into a custom hook for better reusability across other form components.

libs/application/templates/aosh/work-accident-notification/src/fields/AddEmployee/index.tsx (1)

Line range hint 31-46: Consider enhancing error handling for the GraphQL mutation.

The current implementation only shows a generic error message when the mutation fails. Consider capturing and displaying more specific error information to help users understand and resolve issues.

Here's a suggested improvement:

       if (res.data) {
         setUndefinedEmployeeAmount(false)
         setCouldNotAddEmployee(false)
         // Go to screen
         goToScreen && goToScreen(`employeeInformation[${employeeAmount}]`)
       } else {
+        console.error('Failed to add employee:', res.errors)
         setCouldNotAddEmployee(true)
       }

libs/application/templates/aosh/work-accident-notification/src/fields/DeleteEmployee/index.tsx (2)

Line range hint 29-65: Consider extracting array manipulation logic to a shared utility.

The removeAtIndex function and the array update logic could be moved to a shared utility to:

1. Promote code reuse across components
2. Reduce the risk of inconsistent array manipulations
3. Simplify testing and maintenance

Consider creating a utility function like:

// utils/arrayManipulation.ts
export const removeItemAtIndex = <T>(array: T[], index: number): T[] => {
  if (index >= 0 && index < array.length) {
    return [...array.slice(0, index), ...array.slice(index + 1)]
  }
  return array
}

export const updateRelatedArrays = (answers: WorkAccidentNotification, index: number) => {
  return {
    employee: removeItemAtIndex(answers.employee, index),
    absence: removeItemAtIndex(answers.absence, index),
    // ... other arrays
  }
}

---

Line range hint 1-93: Consider generalizing the deletion pattern for reuse across applications.

The component implements a common deletion pattern that could be beneficial across different NextJS apps. Consider:

1. Creating a base deletion component that handles the common logic
2. Using composition to add specific business logic
3. Implementing a hook for the deletion mutation logic

Example approach:

// hooks/useDeleteItem.ts
export const useDeleteItem = <T extends Record<string, any>>(
  updateMutation: MutationFunction,
  options: {
    onSuccess?: () => void;
    buildUpdatePayload: (item: T, index: number) => Partial<T>;
  }
) => {
  // ... implementation
}

// components/base/DeleteButton.tsx
export const DeleteButton: FC<DeleteButtonProps> = ({
  onDelete,
  disabled,
  children,
}) => {
  // ... implementation
}

libs/application/templates/aosh/work-accident-notification/src/fields/Overview/EmployeeAccordionItem.tsx (1)

27-27: Consider maintaining consistency in props usage

While the code works correctly, the component still uses props.field in KeyValueFormField components but excludes it from the destructuring. Consider destructuring the field prop for consistency and clarity.

-  const { application, employee, onClick, index } = props
+  const { application, employee, onClick, index, field } = props

libs/application/templates/aosh/work-accident-notification/src/fields/AccidentLocation/index.tsx (3)

Line range hint 11-14: Enhance type safety for Option interface

Consider making the Option interface more strict and reusable across the application.

-type Option = {
+export interface SelectOption {
   value: string
   label: string
+  disabled?: boolean
 }

---

Line range hint 35-47: Extract filtering logic into a custom hook

The filtering logic for major and minor groups could be extracted into a reusable hook to improve maintainability and reusability across different components.

// useGroupFiltering.ts
export function useGroupFiltering(
  workingEnvironment: WorkingEnvironmentDto[],
  selectedMajorGroup: SelectOption | null
) {
  const majorGroups = useMemo(
    () => workingEnvironment.filter((group) => !group.validToSelect),
    [workingEnvironment]
  );
  
  const minorGroupOptions = useMemo(
    () => selectedMajorGroup
      ? workingEnvironment.filter(
          (group) =>
            group.validToSelect &&
            group.code?.substring(0, 2) === selectedMajorGroup.value?.substring(0, 2)
        )
      : [],
    [workingEnvironment, selectedMajorGroup]
  );

  return { majorGroups, minorGroupOptions };
}

---

Line range hint 89-106: Improve form handling type safety and error states

Consider adding explicit error handling and improving type safety in the form context usage.

 <Controller
+  control={control}
   render={({ field: { onChange }, fieldState: { error } }) => (
     <Select
       required
       label={formatMessage(accident.about.locationOfAccidentMinorGroup)}
       name="accident.accidentLocation"
       options={minorGroupOptions.map((group) => ({
         label: group.name || '',
         value: group.code,
       }))}
       isDisabled={!selectedMajorGroup}
       value={selectedMinorGroup}
       backgroundColor="blue"
+      error={error?.message}
       onChange={(v) => {
         onChange(v);
         setSelectedMinorGroup({
           label: v?.label || '',
           value: v?.value || '',
         });
         setValue('accident.accidentLocation', v);
         setValue(
           'accident.accidentLocationParentGroup',
           selectedMajorGroup,
         );
       }}
     />
   )}
   name={'accident.accidentLocation'}
 />

libs/application/templates/aosh/work-accident-notification/src/lib/dataSchema.ts (3)

Line range hint 89-108: Enhance validation error messages and number parsing

The employment rate validation could be improved for better user experience and robustness:

Consider applying these improvements:

   .refine(
     (data) => {
-      const rateNum = parseInt(data.employmentRate, 10)
+      const rateNum = Number(data.employmentRate)
+      if (isNaN(rateNum)) return false
       return rateNum > 0 && rateNum <= 100
     },
     {
-      message: '1%-100%',
+      message: 'Employment rate must be between 1% and 100%',
       path: ['employmentRate'],
     },
   )

---

Line range hint 110-146: Improve type safety in the cause and effect schema generator

The schema generator uses type assertion which could be made more type-safe.

Consider applying these improvements:

 const createCauseAndEffectSchema = (
   fieldKey: string,
   mostSeriousKey: string,
 ) => {
+  type OptionType = { value: string; label: string }
+  type SchemaType = {
+    [key: string]: OptionType[]
+  }
   return z
     .object({
       [fieldKey]: z
-        .record(z.array(option))
+        .record(z.array(option)) as unknown as z.ZodType<SchemaType>
       [mostSeriousKey]: z.string().optional().nullable(),
     })
     .refine(
       (data) => {
-        // Narrow the type of data[fieldKey]
-        const fieldData = data[fieldKey] as
-          | Record<string, { value: string; label: string }[]>
-          | undefined
+        const fieldData = data[fieldKey]
         if (!fieldData) return false
         const totalOptions = Object.values(fieldData).reduce(
           (sum, arr) => sum + arr.length,
           0,
         )
         return totalOptions < 2 || (totalOptions >= 2 && data[mostSeriousKey])
       },
       {
         path: [mostSeriousKey],
+        message: 'Must select the most serious option when multiple are chosen'
       },
     )
 }

---

Line range hint 1-222: Consider enhancing schema documentation and error handling

While the schema implementation is solid, consider these architectural improvements:

1. Add JSDoc comments to document the purpose and constraints of each schema
2. Implement custom error maps for localization
3. Consider extracting common validation patterns (like kennitala validation) into reusable helpers

Example implementation:

// Helper for kennitala validation
const createKennitalaSchema = (errorMessage?: string) =>
  z.string().refine(
    (value) => value && value.length !== 0 && kennitala.isValid(value),
    { message: errorMessage ?? 'Invalid national ID' }
  );

// Example usage in schemas
const basicCompanySchema = z.object({
  nationalId: createKennitalaSchema('Invalid company ID'),
  // ... rest of the schema
});

libs/application/templates/aosh/work-accident-notification/src/fields/Components/CausesAndEffects.tsx (2)

Line range hint 1-54: LGTM! Consider documenting the new prop.

The type definitions are well-structured and follow TypeScript best practices. The component is properly exported for reuse across different NextJS apps.

Add JSDoc comment for the majorGroupLength prop to explain its purpose:

type CausesAndEffectsProps = {
  externalDataKey: string // Example aoshData.data.physicalActivities
  heading: MessageDescriptor // Contentful translation
  subHeading: MessageDescriptor // Contentful translation
  answerId: string // Example circumstances.physicalActivities
  mostSeriousAnswerId: string // Example circumstances.physicialActivitesMostSerious
  screenId: string // Example circumstances ... used to find answers to autofill
  mostSeriousAnswer?: string // Example physicialActivitiesMostSerious ... used to find answers to autofill
+ /** Length of the major group code used for hierarchical categorization */
  majorGroupLength: number
}

---

Line range hint 120-129: Consider making the validation more explicit.

While the implementation is correct, the early return condition could be more explicit about what constitutes an invalid state.

- if (!code) return
+ if (!code || !value?.value || !value?.label) {
+   setPickedValue(undefined)
+   return
+ }

libs/application/templates/aosh/work-accident-notification/src/fields/Occupation/index.tsx (4)

Line range hint 11-24: Consider extracting a generic hierarchical select component

The current implementation is tightly coupled to the work accident notification domain. Consider extracting the hierarchical selection logic into a reusable component that could be used across different forms.

Example approach:

interface HierarchicalOption {
  code: string
  name: string
  level: number
  validToSelect: boolean
}

interface HierarchicalSelectProps<T extends HierarchicalOption> {
  options: T[]
  value: T | null
  onChange: (value: T | null) => void
  levels: Array<{
    label: string
    filterFn: (option: T, parentValue: T | null) => boolean
  }>
}

---

Line range hint 39-63: Consider using useReducer for complex state management

The component manages multiple related state variables for different selection levels. Consider using useReducer to centralize state management and make state transitions more predictable.

Example approach:

type State = {
  majorGroup: Options | null
  subMajorGroup: Options | null
  minorGroup: Options | null
  unitGroup: Options | null
  searchGroup: Options | null
  options: {
    major: VictimsOccupationDto[]
    subMajor: VictimsOccupationDto[]
    minor: VictimsOccupationDto[]
    unit: VictimsOccupationDto[]
  }
}

type Action = 
  | { type: 'SET_MAJOR_GROUP', payload: Options | null }
  | { type: 'SET_OPTIONS', level: keyof State['options'], payload: VictimsOccupationDto[] }
  // ... other actions

---

Line range hint 273-401: Add form validation for required fields

The form implementation lacks validation rules. Consider adding validation to ensure required fields are filled before form submission.

Example approach:

<Controller
  rules={{
    required: formatMessage(employee.employee.requiredField),
    validate: (value) => {
      if (!value?.value) {
        return formatMessage(employee.employee.invalidSelection)
      }
      return true
    }
  }}
  render={...}
  name={`employee[${idx}].victimsOccupationMajor`}
/>

---

Line range hint 402-430: Enhance accessibility with ARIA attributes

The Select components could benefit from additional ARIA attributes to improve accessibility for screen readers.

Example improvements:

 <Select
   label={formatMessage(employee.employee.unitGroupLabel)}
+  aria-label={formatMessage(employee.employee.unitGroupLabel)}
+  aria-describedby={`occupation-unit-help-${idx}`}
   name={`employee[${idx}].victimsOccupationUnit`}
   // ... other props
 />

Configuration used: .coderabbit.yaml
Review profile: CHILL

#!/bin/bash
# Description: Verify MAX_EMPLOYEES usage in related components

# Check import statements and usage
echo "Checking imports and usage of MAX_EMPLOYEES:"
rg -l "MAX_EMPLOYEES" libs/application/templates/aosh/work-accident-notification/src/

# Check for any remaining hardcoded value of 20 that should use the constant
echo "Checking for hardcoded values that should use MAX_EMPLOYEES:"
rg "20" --type ts libs/application/templates/aosh/work-accident-notification/src/

#!/bin/bash
# Get implementation details from files using MAX_EMPLOYEES

echo "Checking AddEmployee component implementation:"
rg -A 10 "MAX_EMPLOYEES" libs/application/templates/aosh/work-accident-notification/src/fields/AddEmployee/index.tsx

echo -e "\nChecking WorkAccidentNotificationForm implementation:"
rg -A 10 "MAX_EMPLOYEES" libs/application/templates/aosh/work-accident-notification/src/forms/WorkAccidentNotificationForm/index.ts

#!/bin/bash
# Description: Verify that all components are using the updated type import correctly

# Search for any old-style imports that might have been missed
rg -l "import.*WorkAccidentNotification.*dataSchema" libs/application/templates/aosh/work-accident-notification/

# Check for any potential type usage that might need updating
ast-grep --pattern 'WorkAccidentNotification' 

#!/bin/bash
# Check the actual type usage in files to verify consistency
ast-grep --pattern 'type $_ = WorkAccidentNotification'

# Check for any potential interface extensions or type aliases
ast-grep --pattern 'extends WorkAccidentNotification'

# Look at the dataSchema file to understand the type definition
cat libs/application/templates/aosh/work-accident-notification/src/lib/dataSchema.ts

#!/bin/bash
# Description: Verify the WorkAccidentNotification type resolution
# Expected: Find the source file and verify it exports the type

# Find potential source files
echo "Searching for WorkAccidentNotification type definition..."
ast-grep --pattern 'export type WorkAccidentNotification = {
  $$$
}'

# Verify the import path resolution
echo "Verifying import path resolution..."
fd -e ts -e tsx . libs/application/templates/aosh/work-accident-notification/src | xargs rg "export.*WorkAccidentNotification"

#!/bin/bash
# Let's verify the import chain to ensure the type is correctly exported and imported

# Check the content of index.ts to verify the re-export
echo "Content of src/index.ts:"
cat libs/application/templates/aosh/work-accident-notification/src/index.ts

# Check the actual type definition in dataSchema.ts
echo -e "\nContent of src/lib/dataSchema.ts (relevant parts):"
rg -A 5 "WorkAccidentNotification" libs/application/templates/aosh/work-accident-notification/src/lib/dataSchema.ts

#!/bin/bash
# Description: Verify the existence and export of WorkAccidentNotification type
# at the parent directory level

# Check for index files or dataSchema files that might export WorkAccidentNotification
fd -t f -e ts -e tsx "index|dataSchema" "libs/application/templates/aosh/work-accident-notification/src" \
  --exec grep -l "export.*WorkAccidentNotification"

# Verify the import is used consistently across sibling components
fd -t f -e tsx . "libs/application/templates/aosh/work-accident-notification/src/fields" \
  --exec grep -l "import.*WorkAccidentNotification.*from '\.\./\.\.'"

#!/bin/bash
# Let's verify the actual export of WorkAccidentNotification in the identified files
echo "=== Checking src/index.ts ==="
cat libs/application/templates/aosh/work-accident-notification/src/index.ts

echo -e "\n=== Checking src/lib/dataSchema.ts ==="
cat libs/application/templates/aosh/work-accident-notification/src/lib/dataSchema.ts

#!/bin/bash
# Description: Verify the WorkAccidentNotification type export and its usage

# Check the barrel file exports
ast-grep --pattern 'export { $_ as WorkAccidentNotification }'

# Check if there are other components using the same import pattern
rg "import.*WorkAccidentNotification.*from '\.\./\.\.'" libs/

#!/bin/bash
# Check the index.ts/index.tsx files in the work-accident-notification directory for exports
fd -e ts -e tsx "^index\." libs/application/templates/aosh/work-accident-notification/src/ -x cat {}

# Check for the actual type definition
ast-grep --pattern 'type WorkAccidentNotification = $_'

#!/bin/bash
# Check the dataSchema file for the type definition
fd -e ts "dataSchema" libs/application/templates/aosh/work-accident-notification/src/ -x cat {}

-const buildRepeatableSections = (): Section[] => {
-  const sections = [...Array(MAX_EMPLOYEES)].map((_key, index) => {
-    return EmployeeAndAccidentInformationSection(index)
-  })
-  return sections.flat()
-}
+const buildRepeatableSections = (): Section[] => {
+  const sections: Section[] = [];
+  for (let i = 0; i < MAX_EMPLOYEES; i++) {
+    sections.push(...EmployeeAndAccidentInformationSection(i));
+  }
+  return sections;
+}

#!/bin/bash
# Description: Check what's being exported from the parent directory and verify the import path
# Look for the main export file and its contents
fd -e ts -e tsx index --full-path libs/application/templates/aosh/work-accident-notification/src --exec cat {}

# Check if WorkAccidentNotification is re-exported elsewhere
rg -l "export.*WorkAccidentNotification" --type ts --type tsx

#!/bin/bash
# Check for WorkAccidentNotification exports and type definitions
rg -l "export.*WorkAccidentNotification" --type typescript

# Check the content of the parent directory's index file and dataSchema
fd -e ts -e tsx "dataSchema|index" --full-path libs/application/templates/aosh/work-accident-notification/src/lib --exec cat {}

#!/bin/bash
# Check the content of the root index file to see how WorkAccidentNotification is exported
cat libs/application/templates/aosh/work-accident-notification/src/index.ts

# Check for any other potential exports of WorkAccidentNotification
rg "export.*type.*WorkAccidentNotification" --type ts

#!/bin/bash
# Description: Verify the WorkAccidentNotification type export and its usage

# Check if the type is exported from the root index
ast-grep --pattern 'export type WorkAccidentNotification'

# Check for other similar import patterns to ensure consistency
rg -l "import.*WorkAccidentNotification.*from '\.\./\.\.'" libs/application/templates/aosh/work-accident-notification/src/

#!/bin/bash
# Check the root index file content
fd -e ts -e tsx index libs/application/templates/aosh/work-accident-notification/src/ -x cat {}

# Check if WorkAccidentNotification is re-exported from lib/dataSchema
fd -e ts dataSchema libs/application/templates/aosh/work-accident-notification/src/ -x cat {}

#!/bin/bash
# Description: Check if other components use the same import pattern for WorkAccidentNotification

# Search for WorkAccidentNotification imports
rg "import.*WorkAccidentNotification.*from" --type typescript

# Check specifically for any remaining imports from the old path
rg "import.*WorkAccidentNotification.*from.*lib/dataSchema" --type typescript

#!/bin/bash
# Description: Check if other components use the same import pattern for WorkAccidentNotification

# Search for WorkAccidentNotification imports using ripgrep without file type filter
rg "import.*WorkAccidentNotification.*from"

# Check for files that might be importing from lib/dataSchema
rg "import.*from.*lib/dataSchema"

#!/bin/bash
# Description: Check if WorkAccidentNotification type is properly exported and tree-shakeable
# Look for barrel files that might affect tree-shaking

# Check for index files that might affect tree-shaking
fd -e ts -e tsx index libs/application/templates/aosh/work-accident-notification/src --exec rg -l "export.*WorkAccidentNotification"

# Check the actual type definition location
ast-grep --pattern 'type WorkAccidentNotification = {
  $$$
}'

#!/bin/bash
# Let's check the actual type definition and its export
rg -A 5 "type WorkAccidentNotification" libs/application/templates/aosh/work-accident-notification/src

# Check how the type is exported in the index files
cat libs/application/templates/aosh/work-accident-notification/src/index.ts
cat libs/application/templates/aosh/work-accident-notification/src/forms/WorkAccidentNotificationForm/index.ts

#!/bin/bash
# Description: Verify the consistency of WorkAccidentNotification type imports
# and ensure no circular dependencies are introduced

# Check for all WorkAccidentNotification imports
rg --type typescript "import.*WorkAccidentNotification.*from" -A 1

# Check for potential circular dependencies
ast-grep --pattern 'import { $$$ } from "../.."'

#!/bin/bash
# Let's try different approaches to verify the import structure

# Search for any imports from dataSchema
rg "import.*from.*dataSchema"

# Search for EmployeeType imports specifically
rg "import.*EmployeeType"

# Look for files containing both EmployeeType and WorkAccidentNotification
rg "EmployeeType|WorkAccidentNotification" --type ts --type tsx

# Find all TypeScript/React files in the work-accident-notification directory
fd "\.(ts|tsx)$" libs/application/templates/aosh/work-accident-notification

#!/bin/bash
# Let's check the content of the dataSchema file and its usage

# Check the dataSchema file content
cat libs/application/templates/aosh/work-accident-notification/src/lib/dataSchema.ts

# Check how EmployeeType is used in the component
cat libs/application/templates/aosh/work-accident-notification/src/fields/Overview/EmployeeAccordionItem.tsx

#!/bin/bash
# Description: Check component dependencies and usage

# Check for direct imports of this component
rg -l "MultiSelectDropdownController" --type ts --type tsx

# Check for usage of @island.is/application types
ast-grep --pattern 'import { $_ } from "@island.is/application/types"'

# Check for usage of @island.is/application/core
ast-grep --pattern 'import { $_ } from "@island.is/application/core"'

#!/bin/bash
# Let's try a different approach to check component usage and dependencies

# Check for MultiSelectDropdownController usage with proper file extension
rg -l "MultiSelectDropdownController"

# Check imports from @island.is packages using ripgrep
rg -l "@island.is/application/types"
rg -l "@island.is/application/core"

# Look for similar dropdown components
rg -l "MultiSelectDropdown"

# Check the package.json for dependencies
fd "package.json" --exec cat {}

#!/bin/bash
# Check for side effects and verify exports
ast-grep --pattern 'export { $_ }' # Check named exports
ast-grep --pattern 'export default $_' # Check default exports

#!/bin/bash
# Check for side effects in the component file
rg -l "^import.*@island.is/application/types" --type ts
rg -A 5 "^export.*CausesAndEffects" --type ts

#!/bin/bash
# Check the specific file for exports and side effects
rg -A 10 "CausesAndEffects" "libs/application/templates/aosh/work-accident-notification/src/fields/Components/CausesAndEffects.tsx"